Autogenerated HTML docs for v1.6.6.1-383-g5a9f
diff --git a/git-merge.txt b/git-merge.txt index 6747031..d4ef0d0 100644 --- a/git-merge.txt +++ b/git-merge.txt
@@ -10,17 +10,21 @@ -------- [verse] 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]... - [--[no-]rerere-autoupdate] [-m <msg>] <remote>... -'git merge' <msg> HEAD <remote>... + [--[no-]rerere-autoupdate] [-m <msg>] <commit>... +'git merge' <msg> HEAD <commit>... DESCRIPTION ----------- -This is the top-level interface to the merge machinery -which drives multiple merge strategy scripts. +Merges the history specified by <commit> into HEAD, optionally using a +specific merge strategy. -The second syntax (<msg> `HEAD` <remote>) is supported for +The second syntax (<msg> `HEAD` <commit>...) is supported for historical reasons. Do not use it from the command line or in -new scripts. It is the same as `git merge -m <msg> <remote>`. +new scripts. It is the same as `git merge -m <msg> <commit>...`. + +*Warning*: Running 'git merge' with uncommitted changes is +discouraged: while possible, it leaves you in a state that is hard to +back out of in the case of a conflict. OPTIONS @@ -38,16 +42,16 @@ Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible. -<remote>...:: - Other branch heads to merge into our branch. You need at - least one <remote>. Specifying more than one <remote> - obviously means you are trying an Octopus. +<commit>...:: + Commits, usually other branch heads, to merge into our branch. + You need at least one <commit>. Specifying more than one + <commit> obviously means you are trying an Octopus. include::merge-strategies.txt[] If you tried a merge which resulted in complex conflicts and -want to start over, you can recover with 'git-reset'. +want to start over, you can recover with 'git reset'. CONFIGURATION ------------- @@ -101,8 +105,8 @@ will write out your local changes already registered in your index file along with the merge result, which is not good. Because 1. involves only those paths differing between your -branch and the remote branch you are pulling from during the -merge (which is typically a fraction of the whole tree), you can +branch and the branch you are merging +(which is typically a fraction of the whole tree), you can have local modifications in your working tree as long as they do not overlap with what the merge updates. @@ -115,7 +119,7 @@ 3. For conflicting paths, the index file records up to three versions; stage1 stores the version from the common ancestor, - stage2 from `HEAD`, and stage3 from the remote branch (you + stage2 from `HEAD`, and stage3 from the other branch (you can inspect the stages with `git ls-files -u`). The working tree files contain the result of the "merge" program; i.e. 3-way merge results with familiar conflict markers `<<< === >>>`. @@ -194,28 +198,28 @@ * Decide not to merge. The only clean-ups you need are to reset the index file to the `HEAD` commit to reverse 2. and to clean - up working tree changes made by 2. and 3.; 'git-reset --hard' can + up working tree changes made by 2. and 3.; `git-reset --hard` can be used for this. * Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and - 'git-add' them to the index. Use 'git-commit' to seal the deal. + 'git add' them to the index. Use 'git commit' to seal the deal. You can work through the conflict with a number of tools: - * Use a mergetool. 'git mergetool' to launch a graphical + * Use a mergetool. `git mergetool` to launch a graphical mergetool which will work you through the merge. - * Look at the diffs. 'git diff' will show a three-way diff, - highlighting changes from both the HEAD and remote versions. + * Look at the diffs. `git diff` will show a three-way diff, + highlighting changes from both the HEAD and their versions. - * Look at the diffs on their own. 'git log --merge -p <path>' - will show diffs first for the HEAD version and then the - remote version. + * Look at the diffs on their own. `git log --merge -p <path>` + will show diffs first for the HEAD version and then + their version. - * Look at the originals. 'git show :1:filename' shows the - common ancestor, 'git show :2:filename' shows the HEAD - version and 'git show :3:filename' shows the remote version. + * Look at the originals. `git show :1:filename` shows the + common ancestor, `git show :2:filename` shows the HEAD + version and `git show :3:filename` shows their version. EXAMPLES
